Money transfer service with authentication

ABSTRACT

A bank (or merchant) hosts and operates an online money transfer service (or “portal”). A sender logs into the portal and enters payment card and money transfer details and then submits the transaction. An authentication window appears displaying the sender&#39;s transaction details and the sender is prompted to enter his or her password. Upon successful authentication, the bank seeks authorization from the card issuer. Upon successful authorization, the bank credits the recipient&#39;s local bank account or existing payment card. The recipient can also receive a check, a draft, a prepaid card or cash. The money transfer service is used both cross-border and domestic to effect person-to-person money transfer. The money transfer service uses the “Verified by Visa” authentication service and VisaNet for authorization. Messages over VisaNet are used to deliver funds to a recipient.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority of U.S. provisional patent applicationNo. 60/585,670 (Att. Docket VISAP083P), filed Jul. 6, 2004, entitled“Money Transfer Service with Authentication,” which is herebyincorporated by reference.

FIELD OF THE INVENTION

The present invention relates generally to financial transactions. Morespecifically, the present invention relates to an Internet-based moneytransfer service that uses authentication to confirm the identity of thesender.

BACKGROUND OF THE INVENTION

Currently, several Internet-based money transfer services are inoperation. Several of these services do not accept a payment card as asource of funds because of concerns about fraud and chargebacks. Theones that do accept payment cards generally employ one of the followingauthentication methods; these methods can be perceived as less thandesirable.

Some services require paper-based registration where the cardholder isrequired to send a copy of various documents (e.g., passport, socialsecurity card, etc.) to the service by mail or facsimile so that theconsumer can be authenticated. Others use an Address VerificationService (“AVS”)—the cardholder is required to submit his billing addressthat is then verified by the payment card issuer using the AVS whileauthorizing the transaction. As address formats and spellings mightvary, this AVS method is often inexact and inconclusive. Also, billingaddress data is often in the public domain and could be easily availableto criminals. Other money transfer services employ a method in whichtoken funds of a random value are credited to or debited from acardholder's payment card or bank account. The cardholder is thenrequired to read this random entry from his or her account statement,return to an Internet web site, and key in the same. One other techniqueinvolves inserting a random number string (usually four digits) in themerchant name or city field and also posting to the cardholder's accountstatement a small dollar purchase transaction. Cardholders are thenrequired to read this random string from their statement, return to anInternet site, and key in this string.

These techniques have a number of disadvantages. For one, it isinconvenient for the cardholder because of one or more of these reasons:a) physical verification of documents is required; b) inexact andinconclusive verification results; and c) a significant time lag existsbetween the cardholder's first visit to the money transfer web site andthe next visit to complete the transaction. High consumer attritionresults from these inconveniences. These techniques are also more easilyprone to fraud and do not constitute the strong authentication requiredfor mitigating risk of fraudulent transactions and resolving cardholderrepudiation (i.e., “I didn't make this transaction.”) type of disputes.

A bank might choose to trust a cardholder and deliver funds to arecipient without requiring the cardholder to go through an onerousregistration and authentication process, but this approach is likely toentail an unacceptable level of risk to the bank. Even once a cardholderis authenticated using some type of registration process a bank mightstill delay delivery of funds to a recipient until the funds actuallyarrive at the bank. This delay can often be two days or more and isinconvenient for the recipient.

Accordingly, there is a growing need for a quick, convenient and securemoney transfer service that provides for secure authentication of acardholder in a convenient manner and allows a recipient to receivefunds immediately while providing an acceptable level of risk to a bank.

SUMMARY OF THE INVENTION

To achieve the foregoing, and in accordance with the purpose of thepresent invention, a service for cross-border and domestic moneytransfers is disclosed that uses an existing secure authenticationservice.

In one embodiment, a bank (or merchant) hosts and operates an onlinemoney transfer service (a “portal”). A user logs into the portal andenters payment card and money transfer details and then submits thetransaction. An authentication window appears displaying the user'stransaction details and the user is prompted to enter his or herpassword. Upon successful authentication, the bank seeks authorizationfrom the card issuer. Upon successful authorization, the bank creditsthe recipient's local bank account or card. The money transfer servicecan be used for both cross-border and domestic transactions to effectperson-to-person money transfer in a variety of situations. In onespecific embodiment, the money transfer service uses the “Verified byVisa” authentication service (available from Visa International ServiceAssociation, Foster City, Calif.) and Visa's Account Funding Transaction(“AFT”). Visa's Original Credit Transaction (“OCT”) can also be used todeliver funds to a recipient (formerly known as a “CFT”—Cardholder FundsTransfer).

The present invention provides a number of advantages to the cardholder.For one, there is no significant time lag between registration and atransaction: a cardholder may complete a money transfer transaction in afirst session. In fact, registration or log on to the money transferportal is offered as an optional feature without compromising onsecurity, rather than being a mandatory requirement. Consumers are thusspared the burden of yet another user name and password specifically forthe money transfer portal. The cardholder's card is used as the sourceof funds, and these funds can be sent from virtually anywhere in theworld using an online connection. The sender thus does not need todeposit cash at a physical location.

There are also advantages for the recipient of funds. Funds can bereceived at virtually any location in the world; there is no waiting forfunds in a specific embodiment, and the funds do not have to be pickedup from an agent location. Further, the recipient does not have to pickup cash at a physical location if that is undesirable. Unlike prior artservices where a bank might delay delivery of funds, in specificembodiments of the invention (where real-time authentication andauthorization are provided) a bank is guaranteed payment and is thusable to deliver the transferred funds to the recipient nearlyimmediately.

The bank that provides the money transfer service also sees advantages.The simplified registration and transaction processes cut down onoperating costs by providing an alternative for low value cross-borderretail payments that are currently processed through correspondentnetworks. Consumer attrition due to prolonged registration andverification procedures is decreased. The strong authentication providesmuch more robust security than prior methods, and can constitute theproof required for non-repudiation. The sender's issuer bank gains newrevenue opportunities, new customers and provides enhanced service toexisting customers. The recipient's issuing bank avoids cash handlingcosts with the use of prepaid cards, gains new revenue opportunities,and gains access to new customers.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention, together with further advantages thereof, may best beunderstood by reference to the following description taken inconjunction with the accompanying drawings in which:

FIG. 1 is a block diagram illustrating components of a money transferservice.

FIG. 2 is a flow diagram describing how a money transfer service isinitially set up to prepare for user transactions.

FIG. 3 is a flow diagram describing how a money transfer service movesfunds from a sender to a recipient.

FIG. 4 is a block diagram illustrating components of an alternativeembodiment for a money transfer service.

FIG. 5 is a flow diagram describing how the alternative money transferservice moves funds from a sender to a recipient.

FIG. 6 illustrates a confirmation to a sender of funds.

FIG. 7 is a block diagram illustrating a system architecture for theVerified-by-Visa authentication service.

FIG. 8 illustrates a telecommunications network suitable forimplementing an embodiment of the present invention.

FIG. 9 illustrates systems housed within an interchange center toprovide on-line and off-line transaction processing.

FIGS. 10A and 10B illustrate a computer system 900 suitable forimplementing embodiments of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The money transfer service uses an Internet-based portal with whichusers interact. Any bank may, by themselves or in partnership withanother company, set up a money transfer portal in order to facilitatethe domestic or cross-border transfer of funds from one person toanother. A cardholder logs on to the online money transfer portal andtransfers funds to a recipient in the same country or overseas.

For the funding leg, an individual who wishes to send money uses apayment card and internet access to initiate a remittance transaction.Once the individual has logged on to the money transfer portal, he orshe provides details of the payment card used as the source of funds,the remittance order, and the identity of the beneficiary through anonline form. To provide the trust element to the transaction, the portalinitiates an authentication service to confirm the identity of thecardholder; authentication is successfully completed prior to thetransaction being sent for authorization.

As part of this process, the individual enters his or her password tocomplete the authentication. The money transfer portal sends theauthorization request via its acquiring bank to the individual's cardissuing bank. Upon receiving an approval from the sender's issuing bank,the remittance order is confirmed. Clearing and settlement then occursbetween the sender's issuing bank and the money transfer portal'sacquiring bank.

The delivery leg of the remittance process allows for the money transferportal to deliver the remittance amount to the recipient via a modedesired by the sender. The funds may be delivered to the recipient usingtraditional services or instruments such as: a credit to the recipient'sdirect deposit account through interbank clearing; a bank draftdelivered to the recipient or collected in person; or a prepaid cardloaded with the remittance value and delivered to the recipient. Anadditional mode of delivery is performed by crediting an existingpayment card held by the recipient.

The present invention may be used to cover many scenarios, including:salary remittances sent by foreign-born nationals and expatriate workersto support family and friends in their home countries; support forstudents studying or traveling abroad; payments for online auction salesor items bought from classified advertisements; regular payments such asbills, mortgages, alimony and child support payments; gifts orcharitable donations; and small businesses seeking to transfer money.

In one scenario, the money transfer service is used like a “virtual ATM”and individuals may use the service to pay others. An Automated TellerMachine (“ATM”) is a physical access machine where the cardholderprovides his card and a Personal Identification Number (“PIN”) in orderto withdraw cash from the ATM or perhaps provide the cardholder's bankwith a transfer instruction. Frequently, the cardholder would use thiscash to then order a demand draft or banker's check to be sent to abeneficiary. Therefore, in these instances the ATM is acting as a stagein a money transfer operation. Using the present invention, the samecardholder can access the money transfer portal any time and anywhere byproviding card information and a password for authentication and be ableto place instructions for the money transfer. Therefore, for instanceswhere a typical ATM is being used for money transfer, the presentinvention can act as a virtual ATM and replace the need for a cardholderto visit a physical ATM. The following advantages would accrue in thisscenario: access from virtually anywhere; seamless money transfer; and abank is provided with the ability to service cardholders withoutinvesting in individual physical ATMs.

Money Transfer Service Operation

FIG. 1 is a block diagram illustrating components of a money transferservice 10. The below descriptions (together with the full disclosureherein) will be useful in an understanding of the following figures.

Sender 20 is the customer initiating the money transfer. The sender maybe an individual, a small business, etc., or an agent acting on behalfof an individual. For example, people in many parts of the world do nothave Internet access or a payment card. It is contemplated that such aperson may visit an agent's office and request the agent send money to arecipient on behalf of the sender. The sender pays the agent in cash orin any other suitable means. The agent has previously registered (orconcurrently registers) with the authentication service to obtain apassword. The agent uses his or her own registration password andpayment card to transfer funds to the recipient using the money transferservice.

Sender's Issuer 24 is the bank or financial institution that is theissuer of the sender's payment card, such as a credit, debit, commercialor prepaid card. Recipient 30 is the intended recipient of the fundstransferred by the sender. It is also possible that the eventualintended recipient might use an agent to take possession of the funds onhis or her behalf.

Money Transfer Portal 44 is an Internet web site established to collectmoney transfer details from the sender, obtain sender authentication andenable the delivery of the funds to the recipient. The money transferportal can be operated by the service provider bank or by any suitablemerchant.

Service Provider Bank 40 is a bank or financial institution thatoperates the money transfer portal, receives funds from the sender anddelivers funds to the recipient. In the case of a merchant operating theportal, the service provider bank acts as an acquiring bank for themerchant. Delivery of funds is the process in which funds are deliveredto the end recipient. The destination can be virtually any acceptedpayment means. Traditional means such as a bank account credit 70, abank draft or check 74, domestic interbank clearing to credit an account72 of a bank different from the service provider bank, cash 78 or aprepaid card 76 may all be used to deliver funds to the recipient.Further, funds can also be delivered directly to an existing paymentcard account 402 belonging to the recipient (described more fully withreference to FIG. 4). In addition, other types of accounts such as stockbrokerage accounts, mortgage accounts and standard demand depositaccounts may also serve as destination accounts for the receipt of fundson behalf of a recipient.

Authentication service 50 is an Internet-based service that allowsissuers to authenticate their cardholders while an electronictransaction is in progress and to notify the service provider bank (orits merchant) of the results of the authentication before thetransaction continues or before an authorization request is made.Authentication service 50 is more fully described below with referenceto FIG. 7.

VisaNet 60 is an example of a suitable financial network used to supportand deliver authorization and clearing and settlement services. Anysuitable financial network may be used to implement the presentinvention. For example, the “BankNet” financial network available fromMasterCard International is an example of another financial network.VisaNet 60 is more fully described below with reference to FIGS. 8 and9.

Money Transfer Service Setup

FIG. 2 is a flow diagram describing how a money transfer service may beinitially set up to prepare for user transactions.

In step 204 an online authentication service is identified for use withthe money transfer service or a suitable authentication service isdesigned and built. As discussed in greater detail below, any of a widevariety of existing authentication services may be suitable for use withthe present invention and one particular authentication service isidentified and its use is explained. Preferably, a suitable onlineauthentication service provides strong authentication such that acardholder using the money transfer service to send money cannot laterrepudiate the transaction. A suitable service preferably has aregistration component where: a) a cardholder registers in a separatesession in which he or she provides details of the payment card or othermeans that will be used to fund the transaction; b) the cardholderprovides information about himself or herself; c) the cardholderprovides information to the operator of the authentication service (suchas an issuing bank) allowing the operator to reach a reasonableconclusion that the person is who he says he is; and d) the cardholderreceives a token (such as a password) to later use for identificationduring an actual money transfer transaction. In certain embodiments, itis contemplated that such a registration component may take placeconcurrently with the actual money transfer transaction. The means bywhich a sender authenticates himself or herself during an actual moneytransfer transaction (such as by supplying a simple password) ispreferably simple enough and fast enough such that it is convenient fora user during an online transaction. In a preferred embodiment, thesender is provided with the token by his or her issuing bank, ratherthan by a portal. In this way, authentication takes place independent ofthe portal and allows guarantees to take effect. Further detailsregarding a specific authentication service are provided below.

In step 208 an Internet web site is designed and enabled that implementsthe money transfer service portal. The web site is produced by theservice provider bank, on behalf of the bank, or by a company that hasauthorization to run the money transfer service portal and that has amerchant-acquirer relationship with the service provider bank. The website may be implemented using any suitable technologies, userinterfaces, etc. As described below, such a money transfer serviceportal is integrated with an authentication service and relies upon arelationship with an acquiring bank (the service provider bank) tosubmit and process financial transactions. Upon a reading of thisdisclosure, one of skill in the art would be able to implement such aportal. The below lists desirable characteristics of one specificembodiment of a money transfer service portal; other variations arepossible.

The money transfer portal should provide a description of its services.For example, if providing currency conversion, exchange rates should beexplicitly listed as they may vary around the world. The portal shouldprovide customer service contact information, including electronic mailaddress or telephone number. The portal should post its return, refund,and cancellation policy to inform cardholders of their rights andresponsibilities. A given portal might not support delivery ofremittances worldwide and may instead restrict delivery to within theirown country or to a limited number of countries, based oncountry-specific funds transfer regulations. Such country-specific fundstransfers restrictions (if known) or other special conditions should beclearly stated on the portal web site.

The transaction currency should be clearly stated, including the countryname when the name of the unit of currency is not unique. For example, adollar can be an Australian dollar, a U.S. dollar, a Canadian dollar orother. Other information such as a commitment to process orderspromptly, to send an electronic mail confirmation and order summary, astatement of what type of transaction security is supported and astatement encouraging cardholders to retain a copy of the transactionrecord should be present on the web site.

In step 212 the authentication service is integrated into operation ofthe money transfer portal. For example, potential users might visit themoney transfer portal in order to be directed to a suitable site forregistration of the authentication service. Alternatively, registrationfor the authentication service could take place separately from theportal. Preferably, the authentication service is integrated intooperation of the portal such that when a sender is conducting a moneytransfer that the prompt for the sender's authentication token (such asa password) is seamless and convenient. Once authenticated, theauthentication service provides a confirmation to the money transferportal thus allowing the portal operator (or the service provider bank)the opportunity to proceed with obtaining authorization for the moneytransfer.

In step 216 a consumer utilizes a suitable authentication service toobtain a password for use when conducting a money transfer. Preferably,the consumer obtains the password (or token, or supplies biometricinformation) from his or her issuing bank; i.e., the bank that issuesthe payment card to the consumer. A wide variety of authentication meansmay be used by a particular authentication service to authenticate aconsumer. For example, in lieu of a password a user might be asked toprovide answers to certain private questions known only to the user(e.g., what was the name of your favorite pet?) Or, the user may beasked to supply other unique information known only to the user thatmight be different from what is considered to be a traditional password.Or, biometric information might be entered directly into the user'scomputing device (computer, PDA, mobile telephone, ATM, etc.). Forexample, a fingerprint scanner attached directly to such a computingdevice can be used to read a user's finger or thumbprint to authenticatethe user. Or, an iris scanning machine may be connected to the computingdevice and used to authenticate the user. Other means to authenticate auser over an electronic connection are known to those of skill in theart. Once a user has a suitable authentication token or means forproviding one, such a user is able to begin using the money transferservice.

Money Transfer Service Operation

FIG. 3 is a flow diagram describing how a money transfer service 10moves funds from a sender 20 to a recipient 30. In this embodiment, therecipient receives funds into an account, or via a check, cash or newlyissued prepaid card.

In step 304 the sender logs into an Internet web site termed moneytransfer portal 44. Portal 44 is implemented as a web site as known tothose of skill in the art. The connection of the sender to the portal iswell known and can be as simple as providing a URL to a computer havinga suitable Internet connection, and then being presented with the portalweb site. The sender might be required to log into the portal byproviding a user name and portal password, but this is an optional step.

In step 308 the sender enters into the portal web site payment carddetails for the payment card that will be used to fund the moneytransfer. Details such as card account number, sender name, billingaddress, expiry date, type of card, CVV2, etc. might all be input to theportal. In a preferred embodiment, the sender is not required to enterthe CVV2 because the later authentication step provides strongauthentication. In one embodiment, only the sender's name, address, cardaccount number and expiry date are mandatory. The payment card used maybe a credit card, debit card, prepaid card, commercial card or othersuitable payment card, and in a preferred embodiment, these are cardsissued under the guidelines and operating regulations of VisaInternational.

In step 312 the sender provides details on the money transfer such asamount, currency, recipient name and information on the preferred methodof funds delivery. The sender may choose to have the funds delivered toa particular bank and account number, may choose to have the serviceprovider bank issue a bank draft or check, may choose cash, or have thebank issue a new prepaid card to the recipient that stores the transferamount. Alternatively, the sender might give the recipient some choice,by allowing the recipient to choose cash or a prepaid card when therecipient arrives at the bank. If a bank account is used, the accountmay be an “on-us” transaction, meaning that the service provider bank isthe bank that holds the account for the recipient, or the account may bean “off-us” transaction, meaning that the recipient's bank is differentfrom the service provider bank. In one embodiment, the sender selectsfrom a menu of choices on the portal. Once the transfer details areentered, the sender submits the transaction for processing.

In step 314 the money transfer portal conducts any number of preliminarychecks on the information obtained in step 312 to ensure that thetransaction can be completed. These could include a verification thatthe card number entered is valid (using a standard check digitverification algorithm—this eliminates data entry errors), screening ofsender's and recipient's names versus negative lists provided byregulatory agencies, and ascertaining that the transaction amount iswithin limits stipulated by regulatory guidelines. Such checks are wellknown and are done in real time without detracting from the speed orconvenience of the transaction.

In step 316 the portal initiates an authentication service that willauthenticate that the sender is who he says he is. A wide variety ofonline authentication services may be used to authenticate the sender atthis point. For example, the “Secure Code” authentication service usedby MasterCard International would be suitable. Other examples ofauthentication services are: J-Secure from JCB, SET-based systems, PKI,digital certificates etc.

In any case, one of skill in the art upon a reading of this disclosurewould be able to modify an existing (or to be developed) onlineauthentication service to work with the present invention. In onespecific embodiment, the “Verified by Visa” online authenticationservice used by Visa International is initiated. Verified by Visa isknown to those of skill in the art, and is further described below. Toinitiate the service, the portal behaves as a traditional merchant andsubmits a request for authentication to the Verified by Visa service.The service responds by involving a directory server and an accesscontrol server, connecting to the sender's computer and prompting thesender to enter his or her previously registered password (or otherauthentication token or means to authenticate). The access controlserver is controlled by the sender's issuing bank; thus, the issuer isable to authenticate the sender.

In step 320 the sender responds by entering his or her password (orother token or means) into the computer. Knowledge of the correctpassword authenticates the sender. Upon receipt of the correct password,in step 324 the authentication service authenticates the sender andsends a confirmation to the operator of the money transfer portal.

In step 328 the service provider bank sends an authorization request tothe sender's issuer via a suitable financial network such as VisaNet 60.The authorization request is a standard authorization message thatincludes the result from the authentication service. In the VisaNetembodiment, the authorization request uses an AFT authorization requestmessage. An AFT (Account Funding Transaction) is a transaction designedto supply funds to another account such as a Visa prepaid, debit, ATMcard or on-line account, and is explained in more detail below. In thepresent invention, the AFT is paying the service provider bank forsending funds to another party. The AFT eventually will result in adebit to the sender's payment card account. Assuming that funds areavailable from the sender (or that credit is available), the issuerapproves the transaction and the operator of the portal receives anindication via VisaNet that the authorization is successful.

In step 332 the portal confirms to the sender via an on-screen messagethat both authentication and authorization have been successful and thatthe money transfer will occur. Alternatively, or in addition, the portalmay also send an e-mail confirmation message to the sender, such as theexample message shown in FIG. 6. At this point, the sender may choose tolog off of (or simply exit or leave) the money transfer portal web site.Once both authentication and authorization have been successful and theservice provider bank has been so apprised, the service provider bankmay deliver funds to the recipient and may itself be guaranteed paymentof those funds. Because of this guarantee, the portal in step 332 isable to confirm to the sender that payment will be made.

In step 336 the sender confirms to the recipient that the funds will bedelivered via any suitable means such as letter, telephone, shortmessaging service (SMS), electronic mail, instant messaging, etc. Theservice provider bank may also choose to alert the recipient using anyof these methods.

In step 340 the operator of the portal initiates clearing and settlementby submitting a settlement file via the service provider bank intoVisaNet. Within a set period of time Visa will clear and settle thetransaction and move funds from the sender's issuer to the serviceprovider bank. In step 344 the service provider bank delivers thetransferred funds to the recipient. As mentioned above, once the portalreceives confirmation of authentication and authorization, the serviceprovider bank can make the funds available to the recipient in his orher bank account in real time, that is, on the order of seconds, byperforming a real-time posting of funds to the recipient. If therecipient is physically present in a branch of the service providerbank, the recipient can receive a check, prepaid card or cash for theremittance amount within minutes of the confirmation. Delivery of fundscan be immediate. For an “off-us” transaction, an existing electronicinterbank infrastructure is used to move the funds from the serviceprovider bank to the recipient's bank, but the recipient can stillreceive the funds immediately. This situation can occur when the serviceprovider bank is located in the foreign country to which the funds arebeing transferred. An interbank transfer is used to perform the finaldomestic leg of the money transfer.

Regarding the guarantee that the service provider bank receives, thisguarantee may be provided in any number of ways. For example, as theservice provider bank participates in a financial network that providesauthorization, clearing and settlement, the guarantee may be created bycommon agreement amongst those banks and associations that participatein the financial network. In one specific embodiment where the financialnetwork is VisaNet, all Visa member banks have agreed to be bound by aset of operating regulations. These operating regulations include aprovision that once a service provider bank receives confirmation ofauthentication of a sender and the authorization that funds areavailable, the service provider bank is guaranteed payment of thosefunds. Because of this guarantee, a service provider bank can releasefunds in real time to the recipient, thus providing a convenient andattractive benefit to all recipients who wish to receive fundsimmediately. Other methods can be used to provide a guarantee to theservice provider bank (to encourage the service provider bank to releasefunds immediately), for example, a bilateral agreement between theparties.

In step 348 the sender's issuer bills the sender for the remittancetransaction (including any service fees and fees for foreign currencyconversion). This billing step is a standard transaction known the inart. For example, if the sender has used a credit card for the transfer,the charges appear on his or her credit card statement, for a debitcard, the charges are deducted normally from the sender's appropriateaccount. If a prepaid card has been used, the charges are deducted fromthe sender's prepaid card account.

Alternate Money Transfer Service Operation

FIG. 4 is a block diagram illustrating components of an alternativeembodiment for a money transfer service 11. Service 11 includes many ofthe same elements as FIG. 1 and in addition includes recipient's issuer34, a payment card and its associated account 402, and an OCT (OriginalCredit Transaction) message. Recipient's issuer 34 (useful in thisembodiment where the destination account is an existing payment card) isthe bank or financial institution that has issued the payment card tothe recipient. The recipient's issuer credits the recipient's paymentcard account upon receipt of the appropriate transaction from theservice provider bank.

In this embodiment, the recipient's destination account is allowed to bean existing payment card account, and delivery of funds is achieved by acredit to the existing card account. The payment card 402 may be acredit card, debit card, prepaid card or other suitable payment card. AnOCT message is used to submit an original credit through VisaNet to therecipient's issuer.

FIG. 5 is a flow diagram describing how a money transfer service 11moves funds from a sender 20 to a recipient 30. Steps 504 to 540 aresimilar to steps 304 to 340 of FIG. 3. Step 512 is a slight variationfrom step 312 in that the sender chooses to transfer funds to arecipient's payment card, and supplies payment card details such as thetype of card, account number, cardholder name, expiry date, issuing bankand other relevant information depending upon the type of card. In step544 the service provider bank submits an OCT transaction via VisaNet tothe recipient's issuer. The result of the OCT transaction is aninstruction to the recipient's issuer to credit the payment card accountof the recipient; step 544 is typically performed at the end of thebusiness day.

Use of the OCT transaction generally assumes that the service providerbank and the recipient's issuer bank are different banks. In thatsituation, the OCT transaction provides a convenient mechanism for moneytransfer. If the service provider bank and the recipient's issuer bankare the same bank, it is possible for that bank to simply perform aninternal “on-us” credit posting to credit funds to the recipient'spayment card. Nevertheless, it is entirely possible that when theservice provider bank and the recipient's issuer bank are the same bank,that the bank will choose to execute an OCT transaction rather than usetheir internal systems. This situation can occur if it is more difficultfor the bank to connect internal systems than it is to execute an OCTtransaction.

In step 548 the recipient's issuer credits the recipient's payment cardaccount with the amount of the transferred funds. In this embodiment,the time lag from the submission of the OCT transaction by the serviceprovider bank to the actual credit of the recipient's card account isapproximately two business days (48 hours).

In step 552 clearing and settlement occurs between the service providerbank and the recipient's issuer, i.e., the OCT leg of the transaction.Clearing and settling occurs within two business days. In step 556 thesender's issuer bills the sender for the remittance transaction(including any service fees and fees for foreign currency conversion).This billing step is a standard transaction known the in art.

Authentication Service Example

As mentioned above, any suitable online authentication service may beused to implement the present invention. In one specific embodiment, themoney transfer service uses the “Verified by Visa” authenticationservice available from Visa International. Verified by Visa (“VbV”) isan Internet-based service that allows issuers to authenticate theircardholders while an electronic commerce transaction is in progress andto notify the merchant (or other operator of a transaction web site) ofthe results of the authentication before the merchant (or portaloperator) submits an authorization request or otherwise relies upon arepresentation of the cardholder. Up to this point, VbV has been usedfor purchase transactions, but not for money transfer. The presentinvention integrates VbV with a money transfer service to provide a morerobust, convenient and fast money transfer service.

FIG. 7 is a block diagram illustrating a system architecture for the VbVauthentication service. Further details on the service are found in U.S.patent application Ser. Nos. 09/842,313; 10/156,271; 10/370,149;10/660,263; and 10/838,719, all of which are hereby incorporated byreference.

Use of VbV benefits all participants by providing issuers with theability to authenticate cardholders during an online money transfer,thus reducing the likelihood of fraudulent usage of payment cards andimproving transaction performance. For a cardholder to be authenticated,both the money transfer portal operator and the issuer subscribe to theVbV service. Issuers enroll cardholders and assign them a personalpassword. When the cardholder is online attempting to execute anelectronic money transfer the portal operator's system redirects thecardholder to the issuer's site. The issuer then presents a pop-upwindow to the cardholder asking for his or her personal password. Thecardholder types in the password and the issuer validates and confirmsauthentication to the portal operator. Portal operators can use VbV tohelp implement a money transfer service to ensure that senders of moneytransfer transactions are not attempting to transfer funds from a stolenor counterfeit payment card.

Preferably, the money transfer portal ensures that the sender's issuerhas been able to successfully authenticate the cardholder prior tosubmitting the transaction into a financial network (such as VisaNet)for authorization. The service provider bank is thus Verified by Visaenabled and has completed certification to pass relevant authenticationdata into the authorization message and authorization reversal messages.

During the VbV authentication process, issuers generate and send aCardholder Authentication Verification Value (CAVV) in theirauthentication response to the portal operator whenever the cardholderhas been fully authenticated. Acquirers pass the CAVV received from theissuer into the authorization message in order to benefit from theliability shift and interchange benefits associated with fullyauthenticated transactions, and as a condition to use the ElectronicCommerce Indicator (“ECI”) value of 5. Issuers (or Visa on their behalf)validate the CAVV prior to authorizing the transaction (similarly to CVVvalidation). Details of these requirements are available in APML 35/02Verified by Visa: Cardholder Authentication Verification Value (CAVV)Implementation and Interchange Rates, dated 12 Dec. 2002 and in APML01/03 April 2003 VisaNet Business Enhancements Technical Letter UpdateBulletin #1, section 3.3., dated 10 Jan. 2003, each of which is herebyincorporated by reference.

After each successful authenticated transaction (as indicated by a valueof “Y” for Transaction Status in the PARes) the Merchant Server Plug-in(“MPI”) passes specific fields from the PARes to the portal server inorder to correctly identify the transaction in the VisaNet Authorizationprocess. The MPI provides to the portal server the following fields fromthe PARes for use in the VisaNet Authorization request (otherauthorization fields are populated as usual): Transaction Identifier;Cardholder Authentication Verification Value (CAVV); and ElectronicCommerce Indicator.

For fully authenticated transactions, the PARes message sent by theissuer already contains the ECI value set to 5. Acquirer systems shouldbe modified and certified to send the Transaction Identifier, CAVV andECI and to receive the result of the CAVV validation and is returned bythe issuer or Visa on the issuer's behalf prior to the launching of theauthentication service. The above Fields are carried in the followingmessages: Authorization Requests, Responses and Advices; and FullFinancial Requests, Responses and Advices.

Financial Network Example

VisaNet 60 includes the data processing systems, networks and operationsthat are used to support and deliver Visa's authorization and clearingand settlement services.

FIG. 8 illustrates a telecommunications network 800 suitable forimplementing an embodiment of the present invention. The presentinvention may make use of any suitable telecommunications network andmay involve different hardware, different software and/or differentprotocols then those discussed below. The below-described network is apreferred embodiment. Network 800 is a global telecommunications networkthat supports purchase and cash transactions using any bankcard, traveland entertainment cards, and other private label and proprietary cards.The network also supports ATM transactions for other networks,transactions using paper checks, transactions using smart cards andtransactions using other financial instruments.

These transactions are processed through the network's authorization,clearing and settlement services. Authorization is when an issuerapproves or declines a sales transaction before a purchase is finalizedor cash is dispersed. Clearing is when a transaction is delivered froman acquirer to an issuer for posting to the customer's account.Settlement is the process of calculating and determining the netfinancial position of each member for all transactions that are cleared.The actual exchange of funds is a separate process.

Transactions can be authorized, cleared and settled as either a dualmessage or a single message transaction. A dual message transaction issent twice—the first time with only information needed for anauthorization decision, an again later with additional information forclearing and settlement. A single message transaction is sent once forauthorization and contains clearing and settlement information as well.Typically, authorization, clearing and settlement all occur on line.

The main components of telecommunications network 800 are interchangecenters 802, access points 804, 806 and processing centers 808 and 810.Other entities such as drawee banks and third party authorizing agentsmay also connect to the network through an access point. An interchangecenter is a data processing center that may be located anywhere in theworld. In one embodiment, there are two in the United States and oneeach in the United Kingdom and in Japan. Each interchange center housesthe computer system that performs the network transaction processing.The interchange center serves as the control point for thetelecommunication facilities of the network, which comprise high speedleased lines or satellite connections based on IBM SNA protocol.Preferable, lines 820 and 822 that connect an interchange center toremote entities use dedicated high-bandwidth telephone circuits orsatellite connections based on the IBM SNA-LU0 communication protocol.Messages are sent over these lines using any suitable implementation ofthe ISO 8583 standard.

An access point 804 or 806 is typically a small computer system locatedat a processing center that interfaces between the center's hostcomputer and the interchange center. The access point facilitates thetransmission of messages and files between the host and the interchangecenter supporting the authorization, clearing and settlement oftransaction. Links 826 and 828 are typically local links within a centerand use a proprietary message format as prefer by the center.

A data processing center (such as is located within an acquirer, issuer,or other entity) houses processing systems that support merchant andbusiness locations and maintains customer data and billing systems.Preferably, each processing center is linked to one or two interchangecenters. Processors are connected to the closest interchange, and if thenetwork experiences interruptions, the network automatically routestransactions to a secondary interchange center. Each interchange centeris also linked to all of the other interchange centers. This linkingenables processing centers to communicate with each other through one ormore interchange centers. Also, processing centers can access thenetworks of other programs through the interchange center. Further, thenetwork ensures that all links have multiple backups. The connectionfrom one point of the network to another is not usually a fixed link;instead, the interchange center chooses the best possible path at thetime of any given transmission. Rerouting around any faulty link occursautomatically.

FIG. 9 illustrates systems 840 housed within an interchange center toprovide on-line and off-line transaction processing. For dual messagetransaction, authorization system 842 provides authorization. System 842supports on-line and off-line functions, and its file includes internalsystems tables, a customer database and a merchant central file. Theon-line functions of system 842 support dual message authorizationprocessing. This processing involves routing, cardholder and cardverification and stand-in processing, and other functions such as filemaintenance. Off-line functions including reporting, billing, andgenerating recovery bulletins. Reporting includes authorization reports,exception file and advice file reports, POS reports and billing reports.A bridge from system 842 to system 846 makes it possible for membersusing system 842 to communicate with members using system 846 and accessthe SMS gateways to outside networks.

Clearing and settlement system 844 clears and settles previouslyauthorized dual message transactions. Operating six days a week on aglobal basis, system 844 collects financial and non-financialinformation and distributes reports between members. It also calculatesfees, charges and settlement totals and produces reports to help withreconciliation. A bridge forms an interchange between system 844processing centers and system 846 processing centers.

Single message system 846 processes full financial transactions. System846 can also process dual message authorization and clearingtransactions, and communicates with system 842 using a bridge andaccesses outside networks as required. System 846 processes Visa®,Plus®, Interlink® and other card transactions. The SMS files compriseinternal system tables that control system access and processing, andthe cardholder database, which contains files of cardholder data usedfor PIN verification and stand-in processing authorization. System 846on-line functions perform real-time cardholder transaction processingand exception processing for authorization as well as full financialtransactions. System 846 also accumulates reconciliation and settlementtotals. System 846 off-line functions process settlement and fundstransfer requests and provide settlement and activities reporting.Settlement service 848 consolidates the settlement functions of system844 and 846, including Interlink, into a single service for all productsand services. Clearing continues to be performed separately by system844 and system 846.

AFT and OCT Messages

An AFT (Account Funding Transaction) is a transaction designed to supplyfunds to another account such as a credit, prepaid, debit, ATM oron-line account. In the present invention, an AFT is paying the serviceprovider bank for sending funds to the recipient and results in a debitto the sender's card account. The amount of the debit is the amount ofthe credit to be delivered to the recipient plus any fees being chargedby the service provider such as a transfer fee, or a currency conversionfee when the money transfer portal performs currency exchange and itsacquirer submits the transaction in the preferred currency of therecipient.

The following details regarding use of an AFT apply to VbV and VisaNettransactions. One of skill in the art upon a reading of this disclosurewill be able to apply the teachings herein to implement such financialmessages in other authentication and financial network environments.

The AFT indicator is used in both the authorization and clearing andsettlement transactions and is preceded by an authorization. Settlementtakes place within two working days. Neither the authorization nor theclearing transaction carries any financial information about therecipient of a money transfer. The AFT carries only the account numberassociated with the payment card of the sender. An AFT is alsoaccompanied by indicators, which allow the sender's card issuing bank totake appropriate authorization decisions. Indicators include channelinformation such as Mail Order/Telephone Order or Internet, and merchanttype. A financial services association (such as Visa) performs currencyconversion on AFT transactions when the currency of the sender isdifferent from the currency accepted by the service provider. AFTindicators are used to show funds transfers instead of standard purchasetransactions. For AFTs using the VbV Service, it is preferable, forsecurity reasons, that only fully authenticated transactions aresupported. Therefore the response to the authentication request shouldbe ‘Y’ in the VERes and PARes. Therefore, it is preferred that the onlyECI supported is the ECI ‘5’ for AFTs.

The authorization request message is processed as an AFT. Participatingacquirers should use a new pre-determined value in the authorizationrequest to indicate an AFT transaction. Participating acquirers shouldbe able to provide a different new value in the clearing messages toidentify account funding transactions. All subsequent TCRs relating toan AFT should contain the same value in the clearing messages. Thereversal message should be sent prior to the agreed timeline that isstated in the money transfer portal web site. If the cardholder cancelsan approved transaction, a reversal message should be processed via theauthorization system or SMS. In the case that the service provider bankhosts the money transfer portal, a specific Merchant Category Code (MCC)should be used.

The following key fields are used for an AFT and should be supported inmessages and clearing and settlement transactions. The key fields are:Processing Code; Merchant Type; CAVV Result Code; Mail Order/TelephoneOrder/Electronic Commerce Indicator; Mail/Phone/Electronic CommerceIndicator; Transaction ID (XID); and TransStain/CAVV Data.

The messages used to support authorization and SMS VbV/AFT transactionsare the following: authorization requests, responses, and advices; fullfinancial requests, responses, and advices; authorization reversals,reversal responses, and reversal advices. Clearing and settlementrequires the Transaction Code Qualifier be set to ‘1’ in all TCRs forAccount Funding Transactions. The clearing and settlement trancodesneeded to support authorization and SMS VbV/AFT transactions are:Original Sales, Original Credits, Chargebacks, Representments andReversals.

An OCT (Original Credit Transaction) is typically a clearing andsettlement credit transaction designed for use in business applicationssuch as a business money transfer or business-to-consumer repayments.When used in the context of the present invention for money transfer,the OCT is the transaction used to deliver funds to the recipientaccount. It is separate from, and takes place after, the AFTtransaction. This timing is to ensure that payment funds are securedbefore funds are sent to the recipient.

The following details regarding use of an OCT apply to VbV and VisaNettransactions. One of skill in the art upon a reading of this disclosurewill be able to apply the teachings herein to implement such financialmessages in other authentication and financial network environments.

The OCT follows a conventional transaction flow. The amount of the OCTis the amount agreed by the sender and the service provider in thecurrency agreed. If the recipient's billing currency is different fromthe currency agreed at the transaction time, currency conversion isperformed on the OCT and the exact amount credited to the recipientaccount will not be known at transaction time. The OCT carries only theaccount number of the recipient and no information about the sender. Aspecial indicator identifies an OCT to the recipient's issuer bank.Interchange flows from the submitting acquirer to the recipient'sissuer, as in a normal purchase transaction. Settlement takes placewithin two days. Some issuers may delay funds availability for one tothree days, so that further checks can take place.

Transaction data present on an original OCT should be transcribedunchanged onto related exception transactions including chargebacks andreversals. Establishing the ability to link the delivery of fundstransactions to the funding transaction is also useful. OCTs originatingfrom clearing and settlement connected acquirers are identified by apre-determined Transaction Code Qualifier value. No authorizations willbe processed for OCTs originating from clearing and settlement connectedend points. Portal operators should leave the authorization field blankor fill it with zeros. The Electronic Commerce Indicator (ECI) should beincluded on all Internet OCTs. The ECI is required for all Internettransactions. The money transfer portal should use a specific MerchantCategory Code (MCC) to indicate Financial Institutions-Merchandise andServices for both the AFT and OCT transactions. If the cardholdercancels an approved transaction, a reversal message should be processedvia the clearing and settlement system or SMS. If the clearing andsettlement transaction code indicates that a credit voucher has alreadybeen processed, then a clearing and settlement transaction codeindicating credit voucher reversal should be processed.

The following documents contain technical details and the implementationrequirements for Verified by Visa, AFT, and OCT, and are herebyincorporated by reference. Verified by Visa is described in: VbV ServiceDescription; VbV Product Rules and Best Practices; VbV Test MerchantFacility User Guide; CAVV Implementation Guide; VbV AcquirerImplementation Guide; VbV Merchant Implementation Guide; VbV MerchantPlug-In Distribution Plan; and VbV Member and Merchant Brand Guidelines.The AFT and OCT are described in: VisaNet Business Enhancements April2002, Member Technical Letter; VisaNet Business Enhancements April 2002,Member Implementation Guide; Cardholder Funds Transfer Pilot Guidelines;Cardholder Funds Transfer Operating Principles; Cardholder FundsTransfer Acquirer Best Practices Guide; and Cardholder Funds TransferMerchant Best Practices Guide.

Computer System Embodiment

FIGS. 10A and 10B illustrate a computer system 900 suitable forimplementing embodiments of the present invention. FIG. 10A shows onepossible physical form of the computer system. Of course, the computersystem may have many physical forms ranging from an integrated circuit,a printed circuit board and a small handheld device up to a huge supercomputer. Computer system 900 includes a monitor 902, a display 904, ahousing 906, a disk drive 908, a keyboard 910 and a mouse 912. Disk 914is a computer-readable medium used to transfer data to and from computersystem 900.

FIG. 10B is an example of a block diagram for computer system 900.Attached to system bus 920 are a wide variety of subsystems.Processor(s) 922 (also referred to as central processing units, or CPUs)are coupled to storage devices including memory 924. Memory 924 includesrandom access memory (RAM) and read-only memory (ROM). As is well knownin the art, ROM acts to transfer data and instructions uni-directionallyto the CPU and RAM is used typically to transfer data and instructionsin a bi-directional manner. Both of these types of memories may includeany suitable of the computer-readable media described below. A fixeddisk 926 is also coupled bi-directionally to CPU 922; it providesadditional data storage capacity and may also include any of thecomputer-readable media described below. Fixed disk 926 may be used tostore programs, data and the like and is typically a secondary storagemedium (such as a hard disk) that is slower than primary storage. Itwill be appreciated that the information retained within fixed disk 926,may, in appropriate cases, be incorporated in standard fashion asvirtual memory in memory 924. Removable disk 914 may take the form ofany of the computer-readable media described below.

CPU 922 is also coupled to a variety of input/output devices such asdisplay 904, keyboard 910, mouse 912 and speakers 930. In general, aninput/output device may be any of: video displays, track balls, mice,keyboards, microphones, touch-sensitive displays, transducer cardreaders, magnetic or paper tape readers, tablets, styluses, voice orhandwriting recognizers, biometrics readers, or other computers. CPU 922optionally may be coupled to another computer or telecommunicationsnetwork using network interface 940. With such a network interface, itis contemplated that the CPU might receive information from the network,or might output information to the network in the course of Performingthe above-described method steps. Furthermore, method embodiments of thepresent invention may execute solely upon CPU 922 or may execute over anetwork such as the Internet in conjunction with a remote CPU thatshares a portion of the processing.

In addition, embodiments of the present invention further relate tocomputer storage products with a computer-readable medium that havecomputer code thereon for performing various computer-implementedoperations. The media and computer code may be those specially designedand constructed for the purposes of the present invention, or they maybe of the kind well known and available to those having skill in thecomputer software arts. Examples of computer-readable media include, butare not limited to: magnetic media such as hard disks, floppy disks, andmagnetic tape; optical media such as CD-ROMs and holographic devices;magneto-optical media such as floptical disks; and hardware devices thatare specially configured to store and execute program code, such asapplication-specific integrated circuits (ASICs), programmable logicdevices (PLDs) and ROM and RAM devices. Examples of computer codeinclude machine code, such as produced by a compiler, and filescontaining higher level code that are executed by a computer using aninterpreter.

Although the foregoing invention has been described in some detail forpurposes of clarity of understanding, it will be apparent that certainchanges and modifications may be practiced within the scope of theappended claims. Therefore, the described embodiments should be taken asillustrative and not restrictive, and the invention should not belimited to the details given herein but should be defined by thefollowing claims and their full scope of equivalents.

1.-28. (canceled)
 29. A method comprising: receiving, at a computer,payment details for a transaction to provide funds from a sender paymentaccount to a recipient payment account; after receiving the paymentdetails, initiating the sending of an account funding transactionauthorization request message to an issuer of the sender payment accountto authorize the transaction, by the computer; and initiating thesending of an original credit transaction to an issuer of the recipientpayment account.
 30. The method of claim 29 wherein the computer residesat a service provider bank.
 31. The method of claim 30 wherein themethod further comprises performing a clearing and settlement processbetween the service provider bank and the issuer of the recipientpayment account.
 32. The method of claim 31 wherein the method furthercomprises performing a clearing and settlement process between theservice provider bank and the issuer of the sender payment account. 33.The method of claim 32 wherein the sender payment account is associatedwith a payment card of the sender and the recipient payment account isassociated with a payment card of the recipient.
 34. The method of claim29 wherein the computer sends a confirmation message to the senderindicating that the transaction has been authorized and authenticated.35. The method of claim 29 wherein the sender payment account isassociated with a credit card of the sender and the recipient paymentaccount is associated with a debit card of the recipient.
 36. The methodof claim 29 wherein the payment details include an account numberassociated with the sender payment account.
 37. The method of claim 29wherein the payment details include an account number associated withthe sender payment account, a sender name, and a CVV2 value.
 38. Themethod of claim 29 further comprising prompting the sender for apreviously registered password.
 39. A computer comprising: a processorand a computer readable medium coupled to the processor, the computerreadable medium comprising code executable by the processor, forimplementing a method comprising: receiving, at a computer, paymentdetails for a transaction to provide funds from a sender payment accountto a recipient payment account; after receiving the payment details,initiating the sending of an account funding transaction authorizationrequest message to an issuer of the sender payment account to authorizethe transaction, by the computer; and initiating the sending of anoriginal credit transaction to an issuer of the recipient paymentaccount.
 40. The computer of claim 39 wherein the computer resides at aservice provider bank.
 41. The computer of claim 40 wherein the methodfurther comprises performing a clearing and settlement process betweenthe service provider bank and the issuer of the recipient paymentaccount.
 42. The computer of claim 39 wherein the method furthercomprises performing a clearing and settlement process between theservice provider bank and the issuer of the sender payment account. 43.The computer of claim 32 wherein the sender payment account isassociated with a payment card of the sender and the recipient paymentaccount is associated with a payment card of the recipient.
 44. Thecomputer of claim 43 wherein the method further comprises sending aconfirmation message to the sender indicating that the transaction hasbeen authorized and authenticated.
 45. The computer of claim 43 whereinthe sender payment account is associated with a credit card of thesender and the recipient payment account is associated with a debit cardof the recipient.
 46. The computer of claim 39 wherein the paymentdetails include an account number associated with the sender paymentaccount.
 47. The computer of claim 39 wherein the payment detailsinclude an account number associated with the sender payment account, asender name, and a CVV2 value.
 48. The computer of claim 39 furthercomprising prompting the sender for a previously registered password.